Magnum One/Magnum One (Mid-American Digital) (Disc Manufacturing).iso/d1/730k.arc/MAKE730K.TXT

Text File | 1988-03-19 | 6KB | 119 lines

                        October 11, 1987


R. R. Jones
298 Pine Valley Cir.
Lawrenceville, Ga. 30245
MicroNet 70270,117


     I shall not pretend to understand the following
information, nor to assure anyone that it can be repeated in any
other environment, however, it can be repeated here as often as I
like, with delightful results. I pass this along as a procedure
you might want to investigate, and see what your results are. In
any event, whether you succeed or not, it is certainly an
interesting and remarkable phenomenon that has me puzzled.

     I have a generic sort of home-made clone, mostly boards and
hardware from Fountain, a turbo 4.77/8.00 MHZ motherboard, 640K,
a Seagate ST-225 with a standard HD controller, and a Fountain 4
floppy controller card. This allows two Floppies internal, and
provisions through an external connector to add two more on the
outside. I have never used that. For a long time, I ran with one
5.25 floppy as my only drive other than the ST-225. This was a
surplus Cannon (MPI) 2/3 height "junker" I bought from a surplus
house in Doraville, Ga. This drive had a bad chip in the board, I
was lucky in finding it, replaced it, been running fine ever
since. It is about 3 years old, and I do a LOT of hobby
computing, so it is a "tested" component of the system here. It
is so reliable, if I hear any double-seeks, I immediately know
that head cleaning time has arrived.

     Last month I decided to add one of the new 3.5" drives into
the system, I did so, and since I had only a 1/3 opening above
the 5.25 in the case, I elected to mount the 3.5 over the ST-225.
After some trials and tribulations with drive selects, and
fooling around with software I had never seen before (MSDOS 3.2)
I got her a-going, and have been pleased with it. There is an
excellent public domain article written by Frank S. of Suwanee,
Ga. that was helpful in sorting out the software configurations.
This is up on many boards as 730KBDR.ARC. In it, Frank instructs
on the use of the new (DOS3.2) DRIVPARM statement, the method I
chose to get the 3.5 to format correctly. This worked out to:

DRIVPARM = /D:0/F:2/S:9/T:80  {Added to CONFIG.SYS}

Now, you can see that I have put the 3.5 in the system as Drive
A:. Actually, some experimenting around reveals that after the
statement F:2, which defines a quad density 80 track, the rest of
the statement can be left out, it will default to 9 sectors per
track and 80 tracks. Drive B: is now my junk 5.25 floppy.

     You may can guess what happened next. Changing the D:0 to
D:1 causes the thing to want to format 5.25 disks in 80 track
quad-density mode on my B: drive. I observe that the format
appears to be the only place where this information is used, as
after a format, MSDOS is smart enough to look in the Boot Record
and extract the Media Descriptor byte, which I see used to read
the disk. I make this judgement based on the fact that no
information need be provided in CONFIG.SYS in order for the disks
to be read correctly. When the format started, on B:, I observed
a rather different sound to the track steps, a short, clicking
sound I had never heard before.

         You can imagine my surprise when, after the format
program got to head 1, cylinder 40 it kept right on formatting,
all the way to 80 tracks, transferred a system, and asked if I
wanted to do it again!!! I guessed that this was a not-for-real
condition, wherein FORMAT "thought" it had done as told, but in
fact, had created a mess over on the 5.25 drive. However, I here
"capture" a CHKDSK report from drive B:

Sun 10-11-1987
 9:36:27.46
B:\>chkdsk

   730112 bytes total disk space
    45056 bytes in 2 hidden files
    24576 bytes in 1 user files
   660480 bytes available on disk

     The 24576 is, of course, 3.2 COMMAND.COM. I attempted to
transfer information to the disk, delete some files, copy some
more files, add some files of known length, run some software,
type some text files, etc. All normal. After having thoroughly
trashed up the thing, I ran the public domain SST on it, a real
"meanie" on the disk, that sorts the sectors back into contiguous
files. It reported that it was working on a quad-density disk,
sorted and re-wrote FATS and directories, and ended normally.
After that, I ran CHKDSK/V and the report was normal.

     I next completely removed CONFIG.SYS, rebooted, and found
the disk quite readable. I tried this on a total of 9 disks, and
observed that the media is not at all critical. I had some really
old, abused disks and the format worked just fine on all but one.
All reported 730K, and indeed held files to that capacity, except
one, which locked out some bad sectors. I have been through these
disks with Michael Hymans fine EXPLORER. That utility reports
them out as quad-density, reads the sectors, directories, etc.
all normal and as would be expected. I cannot say, now, anything
about the integrity over time on these, as the experience is new.
I am NOT about to use this trick to back-up my ST-225, though the
temptation is there. After some time, and experience, maybe.
Also, without changing cables, I can't observe whether it could
boot from this disk. The 3.5 extends so close to the power supply
cage I can't get that cable off without removing the drive from
the system, more trouble than I have interest in.

     I just can't understand how this can happen. The track
stepping is under control of the floppy chip, and the drives
electronics, and mechanicals, I always thought. But, in this one
particular case, something else I don't understand is involved. I
have no "buddy" with a quad system in order to try reading my
disks on his drives, I don't know what that might reveal.

     I suggest that if this is of interest, and you have 3.2 DOS,
it might be tried and the results noted. I certainly would be
interested, reply to CompuServe 70270,117.